包含建筑物、森林。之前陆陆续续修复了一些,不过都是游击式地修复,没有系统地记录过。现在有时间捡起这件事了,先在这里留个坑吧。
二编:?给房子加layer标签来逃避冲突检查器的检查??这是人类啊?
包含建筑物、森林。之前陆陆续续修复了一些,不过都是游击式地修复,没有系统地记录过。现在有时间捡起这件事了,先在这里留个坑吧。
二编:?给房子加layer标签来逃避冲突检查器的检查??这是人类啊?
Taking a break for 1 week because of ramadhan and installing gentoo as my main system.
I have a large set of photographs I made while running. They are geotagged, as I took them with my phone camera. The compass direction is completely unreliable, but lat/lon is more trustworthy. I thought it would be an interesting experiment to extract greenery like grass and trees from these photographs. It can be a useful addition for creating routes that are more pleasant to walk, since the eye-level point of view is not available in OSM. As this is based on my personal photographs, it has the additional benefit of recommending routes that I tend to use. The first challenge I encountered is that out of a few thousand photographs, only a handful were taken during the daytime. After deduplicating and dropping all photos that contain no greenery, this becomes a relatively small set of waypoints. I decided not to extrapolate additional points along OSM ways to keep the dataset small and avoid adding misleading info. The greenery detection works well enough with the SegFormer model, although it is somewhat slow locally. My plan is to select waypoints from this dataset before calling OSRM. This way I get routes that are more enjoyable to walk and run, but are generally longer than the default shortest route. You can find my dataset on Kaggle.
A few quick notes on some changes I made to OSM based on local knowledge.
Changed the point for the Riverside Centre building to reflect that it is now a Builder’s Corner hardware store.
Added a point for the nearby Hole in the Wall Centre
Defined an area for the Somerset Lofts apartment complex and added some details for it.
I’ve recently begun contributing street-level imagery on Mapillary and Panoramax in my local area. I figured that my dash cam was already recording anyway, so if it could be of use to anyone, why not share it?
Contributing to Mapillary was very easy; since my dash cam has an integrated GPS that encoded its data into the video file, I could just upload the video to Mapillary and their website would turn it into an image sequence. Panoramax requires you to preprocess the video into geotagged images yourself, which made it hard to contribute to. Some cameras can be configured to save periodic images instead of videos, but that didn’t work for me because I still needed the dash cam to work normally as a dash cam first and Panoramax instrument second. It took me a while to figure it out, so I’m writing this blog post to hopefully help out the next guy in the same situation.
The task involves four basic steps. I scripted a solution that works specifically for my dash cam model (Garmin 47) and operating system (Linux). If Panoramax continues to grow, I imagine that separate scripts could be written for each step to mix and match for different camera types and computing environments. The steps are:
Extract the raw GPS data from the dash cam video clip(s)
Along the GPS trace, create a set of evenly-spaced points
Extract images from the video occurring at the evenly-spaced points, and
Add the GPS and time data to the image files
One could go even further and automatically upload the images to Panoramax straight from the terminal, but that’s beyond my coding abilities.
Let’s take a look at each step in detail:
Thankfully, Garmin makes this relatively easy to do with exiftool. If you open the terminal in the directory with the video clips and run the command
exiftool GRMN<number>.MP4
The output will contain a warning:
I spent some time today improving the map data in my local area using the iD editor. As a local, I noticed that several roads were untracted
added roads but i got confused while selecting presets- then i realised the more i do mapping, the better i will get with using presets. Each preset serves a unique purpose.
Few weeks ago i spent time mapping my school in my city, i was soo fun- just wish they could use more updated satelite image.
There has been a very interesting question on the OSM US Slack lately.
“Does anyone have a method to search through the OSM database for a building of a particular shape? I need assistance finding OSM buildings with this specific shape. They should be located in NJ, DE, northeastern MD, eastern PA, or southern NY.”
The question quickly exploded into a huge discussion. At the time of writing, there are already 71 replies.
Someone suggested :
“You could load OSM buildings into PostGIS and then use ST_HausdorffDistance to compare the geometries.”
From there, the discussion veered into how to solve that specific puzzle and find the exact OSM building in question.
One person added, “So the strategy is: create the shape of the building you want to search for, scale it to, say, fill a 100x100 m bounding box or something. Ask Postgres to, within a search-area bounding box, take each building and scale it to a 100x100 m bounding box, compute the Hausdorff distance with the scaled input shape, and return all OSM element IDs and their Hausdorff distances, sorted in ascending order.”
Another said, “What I’m currently doing is combining several shape exports into a single file with around 20,000 objects that have concavity. Concavity plus more than 10 nodes eliminates most buildings.”
At that point, instead of hunting that elusive specific OSM building, I became more interested in the generalized version of the problem.
So I added my two cents to the discussion:
“The generalized version of this problem would be : Can we represent a shape in some kind of data type that allows us to computationally check whether two objects have the same shape, regardless of rotation and scaling?
I haven’t studied the Hausdorff distance yet, but I’m wondering whether it can solve this problem, or if there’s a better alternative—Hu moments, Procrustes analysis, Fourier descriptors for contours…”
Someone replied :
New CNEFE Tool Revolutionizes Street Name Correction in OpenStreetMap Brazil
The community of Brazilian mappers has just gained a powerful ally to improve one of the most crucial and, at the same time, challenging data points in any map: street names. The CNEFE Verification System platform has been launched, accessible at https://cnefe.mapaslivre.com.br, a tool created by and for the OpenStreetMap (OSM) community in Brazil, aimed at validating and correcting address data using the latest information from the 2022 IBGE Census.
The project is an initiative of UMBRAOSM (Union of Brazilian OpenStreetMap Mappers) and was developed by experienced mappers Raphael de Assis, president of UMBRAOSM and member of the OpenStreetMap Foundation, and Anderson Toniazo, both active members of the OSM Brazil community. The tool arrives to solve a long-standing bottleneck in national mapping: the updating and verification of street names based on official sources. The Challenge of Street Names in Brazil
For those mapping in Brazil, one of the biggest challenges has always been the lack of a complete, accurate, and freely accessible street database. Through the Demographic Census, IBGE compiles the National Registry of Addresses for Statistical Purposes (CNEFE) . This registry is a vast list of addresses from across the country, containing street names, address types, neighborhoods, and, in many cases, geographic coordinates, especially in rural and non-residential areas.
Historically, the OSM community has used CNEFE data from previous censuses (such as 2010) to enrich the map. However, the process was complex, involving downloading text files (fixed format), cross-referencing them with census tract shapefiles, and extensive manual work to match the information with the streets already drawn on the map, in addition to correcting spelling differences.
A comunidade de mapeadores brasileiros acaba de ganhar uma poderosa aliada para aprimorar um dos dados mais cruciais e, ao mesmo tempo, desafiadores de qualquer mapa: os nomes das ruas. Foi lançada a plataforma Sistema de Verificação CNEFE, acessível em https://cnefe.mapaslivre.com.br, uma ferramenta criada por e para a comunidade OpenStreetMap (OSM) no Brasil, com o objetivo de validar e corrigir os dados de logradouros utilizando as informações mais recentes do Censo 2022 do IBGE.
O projeto é uma iniciativa da UMBRAOSM (União dos Mapeadores Brasileiros do OpenStreetMap) e foi desenvolvido pelos experientes mapeadores Raphael de Assis, presidente da UMBRAOSM e membro da Fundação OpenStreetMap, e Anderson Toniazo, ambos membros ativos da comunidade OSM Brasil. A ferramenta chega para resolver um antigo gargalo no mapeamento nacional: a atualização e verificação dos nomes das ruas a partir de fontes oficiais . O Desafio dos Nomes de Ruas no Brasil
Para quem mapeia no Brasil, um dos grandes desafios sempre foi a falta de uma base de dados de logradouros completa, precisa e de livre acesso. O IBGE, através do Censo Demográfico, coleta o Cadastro Nacional de Endereços para Fins Estatísticos (CNEFE). Este cadastro é uma vasta lista de endereços de todo o país, contendo nomes de ruas, tipos de logradouro, bairros e, em muitos casos, coordenadas geográficas, especialmente em áreas rurais e não residenciais .
Historicamente, a comunidade OSM já utilizava dados do CNEFE de censos anteriores (como o de 2010) para enriquecer o mapa. No entanto, o processo era complexo, envolvendo o download de arquivos de texto (formato fixo), o cruzamento com shapefiles de setores censitários e um trabalho manual intenso para casar as informações com as ruas já desenhadas no mapa, além de corrigir diferenças de grafia .
Today I contributed to OpenStreetMap by improving map completeness in my local area in Bengaluru, Karnataka.
🔹 What I Worked On
Added a missing café using local knowledge Verified placement to ensure it was mapped at the correct entrance location Added appropriate tags including: amenity=cafe name= ##Bean Stop Café
Checked for duplicate entries before uploading
🔹 Mapping Approach
I focused only on verified, ground-truth information and avoided copying from copyrighted sources. All additions were based on direct familiarity with the area.
🔹 Quality Checks
Ensured the point was not placed on the roadway Confirmed correct spelling and capitalization Reviewed surrounding features for consistency
🔹 Objective
The goal was to improve local POI completeness and contribute accurate, structured data to OpenStreetMap. This is part of my effort to make consistent, quality-focused contributions rather than large, unverified edits.
Hi everyone,
I recently noticed that many modern pedestrian crossings are equipped with automatic detection sensors that trigger the traffic signal without requiring a push button.
Currently, in OpenStreetMap, we can tag:
highway=crossing and crossing=traffic_signals for signalised crossingsbutton_operated=yes/no to indicate if a manual button is presenttraffic_signals:sound=yes/no for auditory signalsHowever, there is no standard way to indicate automatic activation by a detector for pedestrians or vehicles.
To address this, I have proposed a new tag on the OSM forum: detector_operated=yes/no, which would clearly indicate that a traffic signal is automatically triggered by a detector.
You can view and comment on the proposal here: https://community.openstreetmap.org/t/proposal-tag-traffic-signals-detector-operated-pedestrian-presence-sensor/141624
In this changeset (176210161), I focused on improving building-level mapping by adding missing building outlines and refining structural details using Bing Maps aerial imagery.
The objective of this session was to enhance spatial accuracy and improve map completeness in the area. I ensured that:
This edit was completed using the iD editor (v2.37.3), and I requested a review to ensure quality validation and community feedback.
Working on building details helped strengthen my understanding of:
I will continue improving structured building data and map quality in Karnataka.
Today, I worked on improving map data around Yelahanka Taluku, Karnataka. I updated the official name of Sai Vidya Institute of Technology to reflect accurate real-world information and ensured proper tagging consistency.
In addition to correcting the name, I reviewed campus boundary structure, building tagging, and surrounding infrastructure to avoid duplication and maintain data integrity. I verified that the edits align with real-world sources and OSM tagging standards.
My focus during this session was on:
This session helped reinforce the importance of precise tagging, version tracking, and reviewing live map data versus cached tiles. I will continue contributing to improving structured geospatial data across Karnataka.
✅ Info : Problème résolu
Le bloc de béton obsolète à Toulouse (coordonnées : 43,5615376 ; 1,4920996) a été supprimé dans OpenStreetMap.
L’itinéraire cyclable est désormais correct sur Geovelo, sans détour inutile.
Contexte : Le 17 février 2026, j’ai résolu la note #5169818 signalant un problème d’itinéraire cyclable à Toulouse (coordonnées : 43,5615376 ; 1,4920996). Un bloc de béton obsolète (après la fin des travaux) provoquait un détour inutile sur les calculs d’itinéraire.
Actions réalisées : - Correction dans OSM : suppression de l’obstacle (changeset #178691426). - Attente de la mise à jour des données par Geovelo.
Lien direct pour tester : Geovelo - Itinéraire test
À faire : - Vérifier vers le 19 mars 2026 si l’itinéraire est corrigé sur Geovelo/OSRM. - Si le problème persiste, rouvrir la note ou contacter Geovelo.
Localisation : Voir sur OSM
#OpenStreetMap #Toulouse #Vélo #Contribution #Geovelo
Di seguito le persone coinvolte nel progetto: “Pesaro ha bisogno di te!”.
A un gruppo di studenti e studentesse è stato chiesto di incrementare il livello di precisione e accuratezza della mappa nella loro città (e dintorni, alcune e alcuni vivono in zone limitrofe).
Tutte le modifiche saranno ritenute valide se, e solo se, riporteranno l’hashtag #PCTOMarconi2026 e verranno effettuate dagli utenti coinvolti nel progetto di seguito elencati (viene riportato solo il nome utente).
⚠️ In caso di necessità, vi prego di contattarmi via email <giacomo.alessandroni@wikimedia.it> o su Telegram (@galessandroni). In questi canali sono più reattivo rispetto alla messaggistica interna.
Naturalmente, sentitevi liberi di correggere qualsiasi vandalismo refuso doveste notare.

Many people have noticed that publicly available Overpass servers have been suffering from overuse (a typical “tragedy of the commons”). OSM usage policies generally contain the line “OpenStreetMap (OSM) data is free for everyone to use. Our tile servers are not”. Unfortunately, there have been problems with overuse of the public Overpass servers, despite the usage policy. “Just blocking cloud providers” isn’t an option, because (see here - use the translate button below) lots of different sorts of IP addresses, including residential proxy addresses, are the problem.
People who want to use e.g. Overpass Turbo do have the option to point it at a different Overpass API instance. If you’re using Overpass Turbo and you get an error due to unavailability, likely that is because the Overpass API that it is using is overwhelmed. There are other public Overpass API instances, but they may be complete (in terms of geography, or history) or up to date.
Hello! This is my first Diary Entry and I wanted to dedicate it to the Forum Post that I made about the UKs Only (I Believe) ER OUT routes in the case of any emergencies: mainly flooding in this case.
After major flooding in 2013 the council created the Lincolnshire ER Routes to enable people to quickly evacuate from the flood areas. Many of you make have driven past these and never even noticed! They are Red rectangular signs with the white text of ER out on them with a direction to follow. They are placed at every turn, so the evacuees follow the road ahead until a signs says otherwise.

The end of the route signifies that the evacuees are clear of the major flood risk and (presumably) there would be further guidance at the end of the route. The route end sign is the same as the direction signs however it features 5 black diagonal lines.
Σε εφαρμογές που “πατάνε” στους Open Street Maps (σίγουρα στις Mapy. OSMand, Organic Maps, ίσως και αλλού), ως E65 εμφανίζεται ΛΑΘΟΣ ο παλιός δρόμος Λαμία-Δομοκός-Φάρσαλα-Λάρισα και όχι ΣΩΣΤΑ ο αυτοκινητόδρομος Θερμοπύλες-Καλαμπάκα (και ημιτελές Βορειότερα ως την συμβολή με την Εγνατία). Ιδίως για τους ξένους ταξιδιώτες είναι μέγα μπέρδεμα.
2026-02-01に’さくらインターネット Blooming Camp’で行われた「マッパーズサミット2026」での発表内容です
発表内容のうち、OSM wikiに記載されている項目の解説を「OSMの基礎知識編」します
「基礎知識」と思ってバカにしないでください。日本の編集のほとんどすべて(99%以上)がOSM wikiに記載事項に違反しています
また、’talk-ja’などでの意見も OSM wikiに記載事項を理解されていないと思われるものが多いです
![]()
実例を使って交差点のタグ付けを考えて見ましょう。
ちなみに、この例は私の自宅近くにある交差点で一般的なものです、特殊な例ではありません。
junction=yes とします。OSMのマッピングをはじめて、今日で継続年数1年たった。
アカウント自体は5年前に作っていたが、
当時は県道沿いに建物は張り付いてた分しかなくて(うるおぼえ)、
かつて住んでたところくらいはと、3町分の建物を描いたところで、飽きてしまい辞めた。
そして去年の今日、たまたまマップを見てみたら、建物やPOIがかなり充実してたのを見て再燃し、今に至る。
今のところ、熱は冷めてない。
個人的に継続中の調査テーマもあるし、描きたいものもたくさんある。
続けていくつもりなら、いずれはデータを活用する側にも回りたい。
そのためにもマッピングを進めていこうと思う。
オレはようやくのぼりはじめたばかりだからな
このはてしなく遠いマッピング坂をよ……